1. Field of the Invention
The present invention relates to a mobile communication system and a method for providing a messaging service and, more particularly, to a mobile communication system and a method for requesting from group members of a group messaging service a disposition notification of a message status when transmitting the message to the group members.
2. Description of the Related Art
The Open Mobile Alliance (OMA) maintains a standard specification named Instant Messaging based on Session Initiation Protocol for Instant Messaging and Presence Leverage Extensions (SIMPLE IM) service. This instant messaging technology enables groups to transmit/receive messages to/from each other by use of groups defined by each user of an instant message. In this case, a service supported by such instant messaging technology refers to a group messaging service. As described above, the group messaging service is based on the SIMPLE IM service in which multiple users can simultaneously transmit/receive messages to/from each other according to a Session Initiation Protocol (SIP).
In the SIMPLE IM service, after transmitting an IM message, a user on a transmission side often desires to know whether a user on a reception side has actually received the IM message or has read the received IM message. In this case, the user on the transmission side may request a response from the user on the reception side or an IM server on the reception side for Instant Message Disposition Notification (IMDN), which is a processing state of the IM message transmitted from the user on the transmission side. The detailed contents of the IMDN can be checked by reference to Burger, et al., Instant Messaging Disposition Notification, [draft-ietf:simple-imdn-07], Apr. 2, 2008. The IMDN, which the user on the transmission side can request, are largely classified into three types: processing reports, delivery reports, and read reports.
The processing report indicates that the IM message transmitted by the user on the transmission side has been normally processed by the IM sever. This processing report has four attributes. A “processed” attribute indicates that the IM message is normally processed. A “stored” attribute indicates that the IM message is stored in a network for later delivery of the IM message. An “error” attribute indicates that the result of IM message processing cannot be checked. A “forbidden” attribute indicates that the processing report is not allowed.
The delivery report indicates whether the IM message has been delivered to a specified terminal on the reception side. The delivery reports are distinguished by a positive delivery and a negative delivery. This delivery report has four attributes. A “delivered” attribute indicates that the IM message is delivered to the specified terminal on the reception side. A “failed” attribute indicates that the IM message cannot be delivered to the relevant terminal on the reception side. An “error” attribute indicates that it is not possible to check whether the IM message has been delivered to the specified terminal on the reception side. A “forbidden” attribute indicates that the delivery report is not allowed.
The read report indicates whether the user on the reception side has checked or has reproduced the IM message. The read report has three attributes: a “read” attribute indicates that the user on the reception side has checked or has reproduced the IM message; an “error” attribute indicates that it is not possible to know whether the user on the reception side has checked the IM message; and a “forbidden” attribute indicates that the read report is not allowed.
As described above, a network on the reception side or the terminal on the reception side, which has received the IMDN request, may transmit several types of notifications back to a network on the transmission side or the terminal on the transmission side by using the processing report, the delivery report, the read report and so on, depending on the results of IM message processing. Further, a header field, a message format and other details, which are newly defined for expressing the IMDN request and a response to the IMDN request, can be checked in the Burger reference document.
In the group messaging service described above, any user can make requests of the other remaining users for IMDNs when transmitting IM messages to the other remaining users who are participating in the group messaging. However, in a current system, the IM messages transmitted from a sender are delivered to all members, excluding the sender, who are participating in the group messaging. Therefore, if the sender expresses his/her intention for IMDN requests in the IM messages, the other remaining terminals or users that have received the IM messages are requested for the IMDNs. Accordingly, they generate their own reports, and then transmit the generated reports back to the network on the transmission side or the terminal on the transmission side.
However, the method described above is not efficient from the sender's viewpoint, as well as from the networks' viewpoint. When the other remaining users, who have received the IM messages, generate their own reports by the IMDN requests of the sender and then transmit the generated reports to the sender, a large load may be applied to the network, possibly causing network failure. Moreover, when the sender receives the reports from the other remaining recipients even though he/she is interested in only the result of IM message disposition from a particular recipient, the sender may believe that the reports of his/her interest are spam messages.